NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9713

Internet Message Format | 1996-08-05 | 3.9 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: malloc question
Date: Tue, 12 Mar 96 21:10:31 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4htonk$[e-mail]> <[e-mail]> <4hvaj4$[e-mail]> <[e-mail]> <4i1kq3$[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <[e-mail]>
           [e-mail] "Verne Arase" writes:

>In article <4i1kq3$[e-mail]>,
>[e-mail] (Peter Seebach) wrote:

...

>> >And you are _always_ redundant doing so, unless you're passing to a
> >varaidic function or one with no prototype in scope.
>
>I had a pre-ANSI compiler which defined malloc as returning char *.

The C language is that which is defined by the ANSI standard. This has been
around long enough to be definitive as to what the C language is. Your
compiler might be called a pre-ANSI or K&R C compiler but it doesn't qualify
when the discussion is simply about unqualified C compilers. That's just the
way things are, at least in comp.lang.c - you'll find that most questions and
answers implicitly assume ANSI C.

> >char is not a signed quantity.  char is a quantity which may be signed or
> >unsigned.
>
>Every implementation I've seen makes char signed.

That doesn't prove very much. There are real systems out there where
char is unsigned, indeed in some environments char has to be unsigned.
This is because certain characters (A-Z, a-z, 0-9, ! " and others) are
guaranteed to be represented by positive values. If you have, for example,
8 bit characters and a character set where some or all of these have
representations above 127 (e.g. EBCDIC) then a conforming implementation
has no choice but to make char unsigned. On other systems the
hardware archetecture can simply handle unsigned byte values more
efficiently so the compiler naturally chooses them by default (e.g. ARM).

> >It's a question of usage.  An unspecified short, int, or long is *always*
> >signed, so it is clearly desireable for char to be signed.  EOF is
> >negative, and the getc family all return unsigned char or EOF, so it is
> >clearly desireable for char to be unsigned.
>
>While you'd probably want a short, int, or long to be signed, what's the
>percentage of time you actually _want_ char to be signed? And what's the
>percentage of time you gave a hoot whether you had a char * or an unsigned
>char *?

OTOH if I want unsigned char I know where to get it.

>As for the getc routines: don't have any C references here, but don't they
>return an int?

Yes. However the value they return is an unsigned char value converted to
int which is I think what Peter was trying to say. so long as
INT_MAX >= UCHAR_MAX getc() is guaranteed to return a positive value unless
it is flagging an error or end-of-file condition.

> >If you don't put in casts, you will get warnings for any conversion not
> >normally correct.  This is helpful.
>
>Depends on the compiler.

Only if the compiler is non-conforming. ANSI requires invalid implicit
conversions to be diagnosed.

>I've had IDEs where an uncasted pointer conversion just produced an error
>and stopped the compile.

The point is that the compiler tells you about it. The language itself makes
no distinction between warning and errors, it only talks about 'diagnostics'.
The compiler can compile and run any source program you give it whatsoever
so long as it gives you at least one diagnostic when the program contains
one or more syntax errors or constraint violations.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------